前言

「不同系列講的技術主題不一樣,怎麼可能撞題？」

如果每個系列的素材來源都完全獨立,這個疑慮確實不成立。但當手上有好幾個系列的素材其實來自同一個真實經驗——同一套系統的重構過程、同一個寫作專案跟 AI 協作的過程——「主題不一樣」不代表「案例不會撞」。同一個踩坑經驗,換個切入角度講,很容易在讀者沒察覺的情況下,變成兩個系列裡兩個版本不完全一致的故事。這篇要講的,是怎麼在寫之前就把這個風險擋下來,而不是寫完才發現。

今日目標

• 理解「主題不同」不等於「素材不會撞」,尤其是素材同源的系列之間
• 看到一個具體案例：怎麼發現兩個系列的分工邊界描述不夠精確
• 學會用「切入角度」而不是「主題名稱」當作分工的判斷標準
• 知道分工邊界寫進大綱文件之後,還需要在每次動筆前重新核對一次

案例：三個系列共用同一批素材,怎麼劃邊界

這個寫作專案裡,有三個系列的素材都來自同一個來源——這個寫作專案本身跟 AI 協作的真實過程。一個講協作工具本身怎麼設計（skill、CLAUDE.md、memory 的結構),一個講協作時反覆出現的摩擦模式（提前喊停、意圖沒對齊這類行為模式,素材來自使用報告),第三個（也就是這個系列)講參賽這件事本身的排程與紀律。

三個系列的主題名稱一望即知不一樣,但如果只停在「主題名稱不同」就以為分工完成,實際動筆時很容易發生這種情況：

• ❌ 只用主題名稱區分：「這篇講 skill 設計,那篇講協作摩擦,這篇講參賽排程,三個主題聽起來不一樣,應該不會撞。」結果寫到「一支去識別化掃描 script 從無到有的過程」這個案例時,三個系列都覺得這個案例「好像也可以放進來」——工具設計系列覺得這是 skill 附帶工具的案例,協作摩擦系列覺得這是「規則反覆被糾正」的摩擦模式案例,參賽排程系列覺得這是「品質守門怎麼自動化」的案例。同一個案例,三個系列各寫一次,讀者如果三個系列都看,會發現同一件事被講了三次,角度卻沒有真的拉開。
• ✅ 用切入角度區分：同一個案例，工具設計系列該問的是「這支工具的介面設計得好不好、跟其他 skill 怎麼分工」；協作摩擦系列該問的是「這個規則被糾正的過程,反映了哪一種反覆出現的協作摩擦模式」；參賽排程系列該問的是「這個自動化檢查,怎麼被排進每天寫作前的固定流程,對趕進度有什麼幫助」。同一個素材事件,三篇文章各自只回答自己那個角度的問題,讀者看三篇會覺得是三個不同層次的觀察,不是同一件事複述三次。

分工不是靠主題名稱夠不夠不一樣,是靠「面對同一個案例,這篇文章要回答的問題」夠不夠不一樣。

邊界寫進大綱之後,還要在動筆前重新核對

劃清楚切入角度之後,把邊界寫進各自的大綱文件（例如「本系列跟 XX 系列的分工」這種段落),看起來就大功告成了。但實務上,邊界描述容易在寫大綱的當下够清楚,寫到第 15、20 天,面對一個新案例時,還是需要重新核對一次——因為新案例出現時,直覺反應是「這個案例很適合放進我正在寫的這篇」,而不是先想「這個案例的哪個角度屬於這篇文章負責回答的問題」。

• ❌ 直接把案例塞進當天要寫的篇章,理由是「反正主題大方向對得上」
• ✅ 先確認這個案例裡,哪個角度是這篇文章的大綱邊界允許回答的,只寫那個角度,其餘角度留給該負責的系列

今日思考題

如果你手上也有幾份素材來源相近的內容（不管是部落格系列、教材、或報告),你是用「主題名稱」還是用「切入角度/要回答的問題」在區分它們？試著挑一個你覺得可能撞題的案例,問問自己每個系列各自該回答哪個角度的問題。

今日重點回顧

• 主題名稱不同不代表素材不會撞,尤其是素材同源的系列之間
• 分工要用「切入角度/要回答的問題」當標準,不是主題名稱
• 同一個案例,不同系列可以各自只回答自己負責的那個角度,不用整段搬過去
• 邊界寫進大綱文件後,每次動筆遇到新案例時還要重新核對一次,不能只在規劃階段確認一次就假設永遠有效

明日預告

Day 04 會回到賽制規則本身：完賽條件、當日快照、字數門檻這些規則,怎麼在動筆之前就先變成可以檢查的清單,而不是發文之後才想起來對照。

寫在最後

第一次意識到「主題不一樣不代表不會撞」,是回頭看已經寫好的大綱文件,發現分工說明寫得像是「各自負責一塊」,但實際上遇到具體案例時,判斷邏輯還是模糊的。真正解決撞題風險的,不是把分工說明寫得更長,而是換一種問法——面對一個案例,先問「這篇該回答哪個角度」,而不是「這個案例算不算屬於這個主題」。